[Previous] [Next] [Index]
[Thread]
Re: NCSA httpd 1.3 vulnerability still unsolved? (And where to go to solve it?)
On Mon, 3 Apr 1995, Brian Behlendorf wrote:
> The problem was that there are *many* places in the 1.3 code where
> strings are allowed to grow without bounds-checking. The forthcoming 1.4
> fixes a very large number of these (possibly all, but I haven't looked
> closely at 1.4's src enough to say "all").
Indeed. The existing version of NCSA httpd 1.3, even with NCSA's patch,
is *definitely* still exploitable. If you value the safety of your
machine at all, I recommend (for the short term) setting MAX_STRING_LEN
and HUGE_STRING_LEN to the same value. Yes, it's wasteful, but those who
value convenience over security may regret their stance. Thomas has
posted a patch to comp.security.unix that appears to be sufficient (in
most cases) without the large increase in stack size, but it's not a long
term solution either. The entire body of code needs to be rethought. I
don't have access to 1.4, so I don't know what has been done lately.
> If that's not good enough for you now, remember that the bug can only
> really be exploited if you're using a binary that the attacker has access
> to; thus, if you have modified your httpd at all and recompiled, or you
> simply set MAX_STRING_LEN to be another number instead of
> HUGE_STRING_LEN, you will probably be safe until 1.4.
This really isn't true -- it's quite possible, knowing that the hole
exists, to try various combinations of buffer overflows until one
works. It would be obvious to anyone reading the logs what was going on,
but that's not much assurance.
--
Paul Phillips EMAIL: psp@ucsd.edu PHONE: (619) 220-0850
WWW: http://www.primus.com/staff/paulp/ FAX: (619) 220-0873
Follow-Ups:
References: